Land Looking-Around users in Spend > Expenses and add "Send to someone" to a tracked expense's More menu - #97883

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

I looked into the failing checks — there's nothing to fix in the code. Every code/test check passes (typecheck, all 8 test jobs, ESLint, Oxfmt, React Compiler, knip, Storybook, Bun tests, perf tests). The two red checks are both gated on human action, not code:

Since I couldn't run fmt/lint/typecheck in the authoring environment, I want to flag explicitly: CI has now run them and they all pass, so the note in the PR body about those being unverified is resolved.

No code changes were pushed because none are needed — the branch is green on everything a code change could affect.

Both failing checks are human/process gates, not code failures — there's nothing to fix with a push.

• Check independent approval — fails because the PR "does not have enough independent Expensify employee approvals." This clears once an independent Expensify engineer reviews and approves.
• checklist (PR Author Checklist) — fails because "0 out of 38 checklist items" are checked. These are boxes a human author must tick after verifying each item (and filling in the Tests / QA Steps sections) — I don't check them on someone's behalf.

Every actual code/CI check is green: typecheck, ESLint, Oxfmt, React Compiler Compliance, Bun tests, all 8 test jobs, Storybook tests, spellcheck, and the perf tests. So no code change is needed here — the PR just needs the author checklist completed and an independent approval to go green.

@MelvinBot when a new user signs up and selects "Something else" we should still drop them on the Home page, not the Spend page. Then when they make an expense from the Home page, we should drop them into the Spend page.

@MelvinBot for the "Send to someone" menu item - can we place it at the top of the popover menu and put a divider under it?

Updated the Bug 1 approach per your feedback in 340f52e. ✅

What changed:

• Reverted the onboarding-landing change — LOOKING_AROUND ("Something else") users now stay on the Home page after signup, exactly as before. navigateAfterOnboarding.ts is back to its original logic.
• Moved the routing to expense-create time. navigateAfterExpenseCreate.ts now treats a LOOKING_AROUND user as "not on inbox", so when they create an expense from Home they get dropped into Spend › Expenses instead of their self-DM (Personal Space).

So the flow is now: sign up → "Something else" → land on Home → create an expense → land on Spend. Scope is narrow: this only changes routing for LOOKING_AROUND users creating from the global-create button while on the Inbox; every other user is unaffected. Bug 2 ("Send to someone") is untouched.

Verification: fmt, lint-changed, typecheck-tsgo, and the navigation unit tests (navigateAfterExpenseCreate / navigateAfterOnboarding / cleanupAndNavigateAfterExpenseCreate — 35 tests) all pass locally. I couldn't run a live end-to-end check of the fresh-signup onboarding path in this environment (it needs a brand-new "Something else" account, and the test session is an already-onboarded user), so please give the full flow a manual pass when you review.

Re-checked after the latest commit 340f52e — every real code/CI check is green, so there's no code fix to push. The two remaining failures are human/process gates only:

• Check independent approval — fails because the PR "does not have enough independent Expensify employee approvals." Clears once an independent Expensify engineer reviews and approves.
• checklist (PR Author Checklist) — fails because the author checklist boxes aren't ticked. These are items a human author must verify and check off (and fill in the Tests / QA Steps sections) — I don't complete them on someone's behalf.

Passing on this commit: typecheck, all 8 test jobs, Bun tests, ESLint, Oxfmt, React Compiler Compliance, Storybook tests, Compare knip issues, spellcheck, check. The two perf-tests jobs were still running at the time of this check (they passed on the prior run). So no code change is needed — the PR just needs the author checklist filled out and an independent approval.

I re-checked, and the two failing checks are unchanged — both are human/process gates that a code push can't clear, so there's no fix to push:

• Check independent approval — fails because the PR doesn't yet have enough independent Expensify employee approvals. It clears once an independent Expensify engineer approves.
• checklist (PR Author Checklist) — fails because the author checklist boxes (and the Tests / QA Steps sections) aren't filled in. These are for a human author to complete after verifying each item; I don't check them on someone's behalf.

Every code/CI check is green (typecheck, ESLint, Oxfmt, React Compiler Compliance, Bun tests, all test jobs, Storybook, spellcheck; perf tests are still running). No code change is needed — the PR just needs the author checklist completed and an independent approval.

Done — moved "Send to someone" to the top of the More popover with a divider beneath it in 1900f27. ✅

It now sits in its own top section in PopoverMenuSections.ts, so it renders first with a separator under it. New order: Submit it to someone → divider → Split, Merge → Duplicate expense, Move to report → View details, Delete.

Verified on web (created a self-tracked expense, opened Spend › View Expense → More):

More popover — "Submit it to someone" first, divider beneath

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

Rechecked after the latest commit (1900f27) re-triggered CI — every code/CI check is now green (typecheck, ESLint, Oxfmt, React Compiler Compliance, Bun tests, all 8 test jobs, Storybook, spellcheck, perf tests, builds).

The only two remaining red checks are human/process gates that no push can resolve:

• Check independent approval — needs an independent Expensify employee to review and approve the PR.
• checklist (PR Author Checklist) — 0/38 boxes ticked; these are items a human author confirms (plus filling in the Tests / QA Steps sections). I don't check them on someone's behalf.

So there's no code fix to make here — the PR just needs the author checklist completed and an independent approval to go fully green.

Still the same two failures, and both are human/process gates — there's nothing to fix with a code push:

• Check independent approval — fails because the PR "does not have enough independent Expensify employee approvals." Clears once an independent Expensify engineer approves.
• checklist (PR Author Checklist) — fails with "0 out of 38 checklist items" completed. These are boxes a human author must tick (and the Tests / QA Steps sections must be filled in). I don't check them on someone's behalf.

Every actual code/CI check is green (typecheck, ESLint, Oxfmt, React Compiler Compliance, Bun tests, all test jobs, Storybook, spellcheck, perf tests), so no code change is needed. The PR just needs the author checklist completed and an independent approval.

@MelvinBot just tested and a new user who selects "Something else" is still getting directed to the Spend page. Can you confirm your changes made it into the adhoc, or if you made that change at all?

Yes — I made the change, and it's in the latest adhoc but not the first one. It comes down to which build you tested:

• Your first adhoc (triggered 15:05, built from 21df24c7) predates my fix — that build still lands "Something else" users on the Spend tab. If you tested that link, that's exactly what you'd see.
• I pushed the revert in 340f52e at 15:34, so navigateAfterOnboarding.ts:111-114 now falls through to ROUTES.HOME for these users instead of the Spend tab.
• Your second adhoc (triggered 15:55, built from 1900f27) does include the fix. Please retest with that newer build link — the earlier link won't reflect the change.

I also verified at the code level that no other path routes a freshly-onboarded "Something else" user to the Spend/Search tab — that branch only fires on expense creation now (navigateAfterExpenseCreate.ts:69-73) — so reverting the onboarding landing is sufficient to keep them off the Spend tab.

One heads-up on terminology: ROUTES.HOME is the Home dashboard tab, and that dashboard itself renders "Your spend" / "Spend over time" sections. So the page they land on does show spend content, but it is not the Spend (Search) tab. If what you actually want is for them to land on the Inbox tab rather than the Home dashboard, that's a different destination — let me know and I'll switch it.

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

@MelvinBot new user who signs up is still getting dropped into the Spend page. They need to be dropped onto the Home page if they select "Something else". Can you please fix?

I traced this end-to-end and the latest commit on this branch (1900f27) already lands "Something else" (LOOKING_AROUND) signups on the Home page — there is no code path that drops a brand-new "Something else" user onto Spend at signup. So the exact behavior you're asking for is already in the current branch; I think you hit an older build.

What the current code does

• Onboarding completion for "Something else" calls navigateAfterOnboarding, and with no workspace/report it falls through to navigateAfterOnboarding.ts:111-113 → ROUTES.HOME. (My earlier commit reverted the version that sent them to Spend here.)
• The only place a LOOKING_AROUND user is sent to Spend is navigateAfterExpenseCreate.ts:72-73, and that only runs after they actually create an expense from Home — which is the behavior you asked for previously.

I confirmed there's no default-route or "empty inbox → Search" guard that would override this; every signup/init path resolves to Home.

So why are you still seeing Spend? Most likely one of:

1. Stale ad-hoc build — the fix landed at 1900f27 (15:43 UTC today). A build generated before that still contains the old "route to Spend at onboarding" behavior. Please re-test on a fresh ad-hoc build from this commit.
2. You created an expense from Home during the test, which intentionally routes to Spend (per your earlier request).

One honest caveat: I couldn't reproduce the fresh-signup onboarding flow live in this run — the automated test session is an already-onboarded account, and this path needs a brand-new "Something else" signup. My conclusion above is from a full static trace of the code, not a live run.

If you re-test the latest build, don't create an expense, and it still drops you on Spend, please grab a quick screen recording — that would mean there's a runtime path the code trace didn't surface, and I'll dig into that exact scenario.

🚧 shawnborton has triggered a test Expensify/App build. You can view the workflow run here.

@MelvinBot the flow still isn't correct. Here is the desired flow:

1. User signs up and chooses "Something else" from onboarding screen
2. The user lands on the Home page
3. The user creates an expense from the Homepage
4. Once the expense is created, the user is redirected to the Spend > Expenses page

Can you please implement that?

Follow-up review + PR size breakdown (next comment)

1. Review items from the previous pass

Test count went from 4 to 12, and ReportSecondaryActionUtilsTest.ts now covers the new gate. Good.

2. Remaining issues

🟠 Six of eight cleanupAndNavigateAfterExpenseCreate call sites pass isLookingAroundUser without isSelfDMDestination, so the flag is a permanent no-op there

Scoping the gate to isSelfDMDestination was the right fix, but only useExpenseSubmission (lines 373 and 685) actually passes both. Everywhere else:

// ScanSkipConfirmation.tsx:256 and :330
// handleMoneyRequestStepDistanceNavigation.ts:345 and :426
// IOUAmountSubmission.ts:426
isLookingAroundUser,   // ...and no isSelfDMDestination

navigateAfterExpenseCreate defaults isSelfDMDestination = false, so the gate evaluates as:

const isUserOnInbox = isReportTopmostSplitNavigator() && !(true && false);  // -> unchanged

Bug this causes: Bug 1 is only actually fixed for the confirmation-step path. A brand-new LOOKING_AROUND user who takes a photo and skips confirmation, or enters an amount via QAB, or logs a distance and skips, still gets dumped into Personal Space. That is the single most common way a new user creates their first expense, so the headline bug is unfixed on the path that matters most.

SubmitDetailsPage is one word away from correct: it already computes isSelfDM(report) at line 296 for the pre-mount builder, but doesn't pass it at line 476.

Two of the six are dead by construction rather than by omission: DynamicIOURequestStepCompanyInfo.tsx:143 and useExpenseSubmission.ts:1099 are both isInvoice: true paths, where the self-DM is never the destination. DynamicIOURequestStepCompanyInfo also added a whole new useOnyx(ONYXKEYS.NVP_INTRO_SELECTED) subscription to feed a flag that can never fire.

Fix: either wire isSelfDMDestination into the three real skip call sites, or drop the flag from all five dead ones and scope Bug 1 to the confirmation step explicitly with a follow-up issue. Right now it reads as covered when it isn't.

🟠 getSkipConfirmationPreMountDestinationRoute still untouched (carried over)

function getSkipConfirmationPreMountDestinationRoute(shouldSkipConfirmation: boolean, reportID: string | undefined): Route | undefined {
    if (!shouldSkipConfirmation || isSearchTopmostFullScreenRoute() || !reportID) {
        return undefined;
    }
    return ROUTES.REPORT_WITH_ID.getRoute(reportID);
}

If the skip call sites above get isSelfDMDestination wired, this builder needs the same !(isLookingAroundUser && isSelfDMDestination) guard that getSubmitExpensePreMountDestinationRoute got. Otherwise the self-DM gets pre-inserted behind the RHP on narrow layout and then force-replaced to Search, which is the Personal Space flash the pre-insert machinery exists to prevent. This is why the two issues have to be fixed together, not separately.

🟡 submit2026 divergence on the new row

The component now reads isSubmit2026BetaEnabled for the hasWorkspaceToSubmitTo selector, but the row itself still calls createDraftTransactionAndNavigateToParticipantSelector with the default submitDestination = FRIEND. Under the beta, the whisper and the report-details menu both split into "Submit to a friend" / "Submit to my employer"; the header row offers only the friend path. Defensible now that the label is literally "Send to someone", but worth confirming with design rather than leaving implicit.

🟢 New row skips the write-action guard its neighbour uses. MOVE_EXPENSE, directly above it, ends with canUserPerformWriteActionReportUtils(parentReport, isChatReportArchived). SEND_TO_SOMEONE has no equivalent, so it still renders on an archived self-DM. isChatReportArchived is already a parameter.

🟢 Tests / Offline tests / QA Steps are still the empty template, and the PR is no longer a draft. Given the concerns being raised about this PR, this is the cheapest thing to fix and probably the biggest driver of the "not going well" perception.

3. Size breakdown: what is actually causing the diff size

Current diff: 380 added / 8 removed across 32 files. Split by concern:

My intuition on Slack was that the bulk came from "Send to someone" being a new feature. The data says the opposite. The navigation fix is roughly 2x the size of the new feature, and that ratio holds even if you strip tests out (112 vs 92 production lines).

Why Bug 1 is big, and why that is not the author's doing.

Post-create routing in this codebase is decided by three functions that must agree with each other:

• getSubmitExpensePreMountDestinationRoute (what gets pre-mounted behind the RHP)
• getSubmitHandler (which dismiss strategy runs)
• navigateAfterExpenseCreate (where you actually land)

If you change one and not the others, you get a visible flash or a stale route. So any change to "where does a user land after creating an expense" is a minimum of three coordinated edits plus every call site that feeds them. Of Bug 1's 112 production lines, only about 40 are actual decision logic. The other ~72 are threading one boolean through 8 call sites and 2 param types, at 2 to 9 lines each. That fan-out is pre-existing architecture. Nobody, under any author, does this in fewer files.

Why Bug 2 is smaller than it sounds.

"Send to someone" reuses createDraftTransactionAndNavigateToParticipantSelector wholesale. Zero new picker, zero new routes, zero new API, zero new RHP screens. It is 62 lines in one component, 16 in one util, one CONST key, one gate, and 11 one-line translation adds. For a new More-menu action in this repo that is close to the floor. Compare DynamicReportDetailsPage.tsx:555-627, which spends ~70 lines on the same capability.

What is genuinely removable right now: about 19 lines across 5 files (the dead call sites in section 2), which is ~5% of the diff. That is real, and it should go. It is not "much bigger than needed."

4. Verdict

The concern that this PR grew beyond the issue is fair on its face, but the cause is being misattributed. It is not the new feature and it is not the author. It is that the issue bundles a 1-line-looking behaviour change that sits behind a 3-function navigation contract with a genuinely new UI surface. Either one alone would be a normal-sized PR. Together they read as sprawl.

Reassigning the PR to a different author changes the diff by zero lines. Both halves are structurally required regardless of who writes them. If we want a smaller PR, the lever is scope, not authorship.

5. Options, graded by resulting PR size

A. Melvin finishes this PR as-is, both bugs (recommended)

• Remaining work is 4 mechanical items, all specified above: pass isSelfDMDestination at the 3 real skip call sites, drop isLookingAroundUser from the 2 invoice call sites where it cannot fire, add the !(isLookingAroundUser && isSelfDMDestination) guard to getSkipConfirmationPreMountDestinationRoute, add canUserPerformWriteActionReportUtils to the SEND_TO_SOMEONE gate. Plus fill in Tests / Offline tests / QA Steps and attach the 5 platform recordings.
• Result: ~400 lines / 28 files. Slightly bigger than today, and Bug 1 is actually complete rather than silently covering only the confirmation path.
• Rationale: the last round addressed 7 of 8 findings correctly on the first pass, including the two 🔴 ones, and the author independently reverted navigateAfterOnboarding.ts rather than defending it. Nothing in the code or the response pattern justifies a handoff. What's left is threading a boolean that already has its param, its type, and its tests in place.

B. Melvin finishes, but Bug 1 is scoped to the confirmation step

• Drop isLookingAroundUser from the 5 call sites where it currently does nothing, say plainly in the description that Bug 1 covers the confirmation-step path only, file a follow-up for scan-skip / distance-skip / QAB.
• Result: ~361 lines / 27 files. Smallest honest single-PR option.
• Cost: scan-and-skip is the most common way a brand-new user creates their first expense, so the headline bug stays broken on the path that matters most. Only worth it if there is schedule pressure.

C. Split into two PRs, same author

• PR 1: "Send to someone" only, ~129 lines / 16 files, self-contained, green on every item above, mergeable now. PR 2: LOOKING_AROUND routing, done properly, ~275 lines / 17 files.
• Result: two smaller diffs, two review cycles. Worth it only if the objection is genuinely "this diff is too much to hold in my head at once," since that is the one thing splitting actually solves.

D. Reassign the PR to a different author

• Result: 380 lines / 32 files, identical. Both halves are structurally required regardless of who writes them.
• The only delta is losing the review context already built up here, and restarting the fix cycle on findings that are already fixed. If the concern is author responsiveness rather than diff size, that is worth saying out loud, because the evidence on this PR points the other way.

My recommendation is A. If the goal is specifically a smaller diff rather than a finished fix, C is the honest way to get there; D does not get there at all.

cc @shawnborton @tgolen noting once again that me re-opening the PR will only lose review context - it won't change the options, so my take is to move forward with Melvin in this PR regardless of selected option

Thank you for that detailed breakdown, that is helpful! @tgolen any thoughts? Maybe we see if Melvin can do Option A above.

@MelvinBot can you take a look at the latest comment and do Option A above, as well as fix conflicts?

Did Option A + resolved conflicts

Pushed f2cf27d on top of a clean main merge. npm run fmt, npm run lint-changed, npm run typecheck-tsgo, and the affected unit suites all pass locally. ikevin127 — this maps to your four Option A items plus the Tests/QA fill.

Conflicts

Merged origin/main into the branch. Only one file conflicted — handleMoneyRequestStepDistanceNavigation.ts — a both-added case (main added selectedRouteDistance, this PR added isLookingAroundUser); kept both.

Option A — the four mechanical items

Net effect: Bug 1 is now actually fixed on the scan-skip / distance-skip / QAB paths (the most common way a new user creates their first expense), not just the confirmation step — and the two invoice sites no longer carry a flag that can never fire.

Tests

• Added a LOOKING_AROUND self-DM guard case (and two negative cases) to getSkipConfirmationPreMountDestinationRouteTest, and an archived-self-DM case to the SEND_TO_SOMEONE gate in ReportSecondaryActionUtilsTest.
• Filled in the Tests, Offline tests, and QA Steps sections of the PR description with end-to-end repro steps for both bugs (including each create entry type and the narrow-layout no-flash check).

Honest caveats

• I couldn't drive a brand-new "Something else" signup or the narrow-layout native/mWeb skip flows in this environment, so the skip-path behavior is verified by code trace + unit tests, not a live run. Please give the scan-skip / distance / QAB paths a manual pass on a fresh ad-hoc from f2cf27d.
• react-compiler-compliance-check check-changed couldn't resolve a base ref in this shallow checkout. Running check directly flags pre-existing memoization in IOURequestStepDistance.tsx at unrelated useCallbacks (lines ~632/781) — a grandfathered file; my additions (isLookingAroundUser, isSelfDM(report)) aren't referenced in any memoized block, so there's no new regression. CI's check-changed (regression-only) will confirm.
• The platform-testing / screenshots / "no console errors" checklist boxes still need a human — I don't attest those.

I left the submit2026 two-destination split out (that's a coupled UX + copy decision, per the earlier thread). Let me know if you'd like me to pick that up too.

Nice, let me know how that is feeling @ikevin127 @tgolen

In the meantime, @MelvinBot can you try to fix the failing tests

Fixed the failing checks in 668fe15. Three were red on real code — all now resolved locally (fmt, ESLint on the touched files, React Compiler compliance, and spellcheck all pass):

• React Compiler Compliance + ESLint check (same root cause) — IOURequestStepDistance.tsx is already sitting at React Compiler's memoization-preservation limit. The extra top-level isLookingAroundUser const I added in the last round tipped it over, which made the compiler skip the whole component and un-relaxed the preserve-manual-memoization rule on two pre-existing useCallbacks (nothing I wrote). Fix: compute the LOOKING_AROUND + self-DM flags inline at the call site instead of hoisting a new reactive const — the component compiles again and both checks go green. Left a comment there so nobody re-extracts it.
• spellcheck — reworded misrouted in navigateAfterExpenseCreate.ts and fixed a pre-existing overriden → overridden typo that surfaced because these files are now in the diff.

The only remaining red checks are the two human/process gates — Check independent approval (needs an independent Expensify approval) and checklist (PR Author Checklist) — which no code push can clear.

Taking a look at this now and I'll let you know what I think!

Oops, I meant for that review to be "request changes" and clicked on the wrong button. Please address the comments :D

I will remove my review request, but let me know if there is anything you want my take on 🙌

@MelvinBot can you please review the comments from Tim and address them?

Looks like we're moving with option A with some caveats. All that's left from my side is to complete the PR Reviewer Checklist including running the manual tests.

I'll do that shortly and will report back on how / what works ✅

Addressed tgolen's review comments

Pushed 0ee2434. npm run fmt, lint, and the affected unit suites pass locally (192 + 81 tests green). Replied in-thread on each of Tim's comments; summary:

One thing worth flagging: the reason navigateAfterOnboarding.ts was still in the diff wasn't the Looking-Around change (already reverted) — the file had picked up an unrelated change to navigateToSubmitWorkspaceAfterOnboarding that reroutes it from Spend › Expenses to Workspace › Categories. That isn't on main and isn't part of this PR, so I dropped it with the revert. If that reroute is actually wanted, it should go in its own PR.

Review of f2cf27d → 0ee2434 (Option A round)

Summary

One blocker (the navigateAfterOnboarding revert), three small cleanups, and seven manual steps to add. Everything from the Option A list landed correctly. Once the revert is undone I'll run the full manual pass across the 5 platforms and complete the Reviewer Checklist.

Verified against the current diff (437 added / 25 removed, 36 files) and against origin/main via git merge-base. CI is green on everything except the two human gates.

1. Option A items

Bug 1 now genuinely covers scan-skip, distance-skip and QAB, not just the confirmation step. Test count is 16 across 5 files. That part is done.

2. Findings

🔴 navigateAfterOnboarding.ts reverts a change that is currently on main — blocking

The claim in this comment and the inline reply is that the navigateToSubmitWorkspaceAfterOnboarding reroute "isn't on main" and was therefore dropped. That is backwards. gh pr diff diffs against the merge base, and this file shows 4 + / 9 -:

-    const categoriesRoute = ROUTES.WORKSPACE_CATEGORIES.getRoute(policyID);
-    const backToRoute = shouldUseNarrowLayout ? ROUTES.WORKSPACE_INITIAL.getRoute(policyID) : ROUTES.WORKSPACES_LIST.route;
-    Navigation.navigate(`${categoriesRoute}?backTo=${encodeURIComponent(backToRoute)}` as Route);
-
+    Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: buildCannedSearchQuery({type: CONST.SEARCH.DATA_TYPES.EXPENSE})}));

Verified locally:

$ git show $(git merge-base HEAD origin/main):src/libs/navigateAfterOnboarding.ts | grep -c categoriesRoute
2
$ git show HEAD:src/libs/navigateAfterOnboarding.ts | grep -c categoriesRoute
0
$ git show origin/main:src/libs/navigateAfterOnboarding.ts | grep -c categoriesRoute
2

The Workspace › Categories routing has been on main since bd5daef6e46 (the reordered-onboarding-accounting-flow work). The "revert to main" took the file back to a pre-bd5daef state instead.

Bug this causes: a user who creates or joins a Submit workspace during onboarding currently lands on Workspace › Categories with the side panel open (the designed flow, with a layout-aware backTo). With this PR merged they land on Spend › Expenses instead, and the backTo is gone. That is an unrelated onboarding flow silently regressing inside a PR about Looking-Around routing, and nothing in this PR's test steps would catch it.

Fix: restore the file to the current merge-base state so it drops out of the diff entirely:

git checkout $(git merge-base HEAD origin/main) -- src/libs/navigateAfterOnboarding.ts

The buildCannedSearchQuery import and the Route type import go with it.

🟡 Two different predicates for isSelfDMDestination across the skip flows

The pre-mount guard only works if it suppresses in exactly the cases where the navigate half forces Search. Right now three screens do not agree on how that is computed:

Being straight about this: I traced the Amount and Distance paths and could not construct a case where the two actually disagree today, because when report is undefined the builder already bails on !reportID. So this is not a demonstrated bug. It is a latent one, and it is specifically the class of mismatch the guard exists to prevent, so it should not rely on !reportID covering for it. transaction?.participants is in scope in both screens (IOURequestStepAmount.tsx:127 already uses it), so both can use the same predicate as their navigate half:

const skipConfirmationPreMountRoute = getSkipConfirmationPreMountDestinationRoute(
    shouldSkipConfirmation,
    report?.reportID,
    introSelected?.choice === CONST.ONBOARDING_CHOICES.LOOKING_AROUND,
    isSelfDMSoleDestination(transaction?.participants ?? [], iouType, currentUserPersonalDetails.accountID),
);

🟡 The new SEND_TO_SOMEONE gate tests leak spies into every later test in the file

tests/unit/ReportSecondaryActionUtilsTest.ts — getSendToSomeoneResult sets three spies and never restores them:

jest.spyOn(ReportUtils, 'isTrackExpenseReportNew').mockReturnValue(true);
jest.spyOn(ReportUtils, 'canUserPerformWriteAction').mockReturnValue(!isChatReportArchived);
jest.spyOn(TransactionUtils, 'getOriginalTransactionWithSplitInfo').mockReturnValue({...});

The enclosing describe runs jest.clearAllMocks() in its beforeEach, which resets mock.calls but not mockReturnValue, and there is no restoreMocks in jest.config.js, jest/setupAfterEnv.ts, or the jest-expo preset. So every test declared after this block inside getSecondaryTransactionThreadActions runs with isTrackExpenseReportNew → true, canUserPerformWriteAction → false and a mocked getOriginalTransactionWithSplitInfo.

I ran the suite and it is green today (56 passed), so nothing is broken right now. But the next person adding a case below this block gets a silent false result. One line fixes it:

describe('SEND_TO_SOMEONE gate', () => {
    afterEach(() => {
        jest.restoreAllMocks();
    });

🟡 isLookingAroundUserSelector re-adds the one-liner that was just deleted

tgolen asked for isLookingAroundOnboardingChoice to be removed and inlined, which was done. But src/selectors/Onboarding.ts now adds:

function isLookingAroundUserSelector(introSelected: OnyxValue<typeof ONYXKEYS.NVP_INTRO_SELECTED>): boolean {
    return introSelected?.choice === CONST.ONBOARDING_CHOICES.LOOKING_AROUND;
}

I think this one is justified and should stay: a useOnyx selector needs a stable module-level identity, and it sits directly next to the identical isTrackIntentUserSelector, so it follows existing precedent rather than inventing a pattern. Flagging it only so it doesn't read as the same thing being re-added. @tgolen worth a quick confirm that the selector form is fine with you.

🟡 The PR's own Tests section uses the old label

Steps 3 and 6 of Bug 2 say "Submit it to someone", but the row now renders iou.sendToSomeone = "Send to someone". QA will look for a string that no longer exists.

3. Do the listed manual tests cover the diff ?

Mostly yes for Bug 1, and there are real gaps for Bug 2 and for the regression surface.

Well covered: the signup → Home → create → Spend loop across manual / scan-skip / distance, the narrow-layout no-flash check (this is the one that exercises the new getSkipConfirmationPreMountDestinationRoute guard), and the "user with a workspace still lands on their report" regression case, which is the guard that took three rounds to get right.

Missing, and worth adding before QA:

1. Whisper resolution after "Send to someone." This is the fix for the most severe bug found in this PR and no step verifies it. Add: after step 5, go back to Personal Space and confirm the original "Submit it to someone / Categorize it / Share it" whisper is resolved and no longer offers actions on the sent expense.
2. The split-expense gate. !isSelfDMExpenseSplit || hasWorkspaceToSubmitTo is new logic with no manual step. Two cases: self-DM split expense with no workspace → row hidden; same user after joining a workspace → row appears.
3. Invoice regression. isLookingAroundUser was removed from both invoice call sites. Add: as a Looking-Around user, create an invoice and confirm the landing is unchanged.
4. Submit-workspace onboarding. Because of finding 🔴 above, create or join a Submit workspace during onboarding and confirm you land on Workspace › Categories with the side panel open. This currently fails.
5. Share flow. SubmitDetailsPage changed on both the pre-mount and cleanup halves; the Android/iOS share sheet → Submit details path has no step.
6. QAB split out from scan-skip. Step 3 folds "scan a receipt then skip confirmation (via the quick action button)" into one item, but those are two separate code paths (ScanSkipConfirmation vs IOUAmountSubmission.submitSkipConfirmationExpense reached from IOURequestStepAmount). Both changed, so both need their own step.
7. Delegate-restricted account. Tapping the row should show the no-access modal and not create a draft.

Offline section: step 2 is the right one. Step 3 ("row still appears offline") is trivially true and adds nothing. Replace it with the two that actually exercise the changed code: submit the "Send to someone" conversion while offline and confirm the whisper resolves optimistically; then force a failure and confirm the whisper rolls back to unresolved, since that rollback is gated on the same actionableWhisperReportActionID that was undefined two rounds ago.

@MelvinBot We need these addressed before proceeding with manual testing and merging.

Coming from here, understanding the caveats, and whether they affect issue #97881 expected result

Issue #97881 asks for exactly two things: land in Spend › Expenses after the first expense, and have "Send to someone" under More using the same flow as from the Inbox.

On that last one, concretely. With SUBMIT_2026 off, the Inbox whisper offers a single "Submit it to someone" and so does the More row, so the issue's "same flow as from the Inbox" is satisfied. With the beta on, the whisper and the report-details menu both split into "Submit to a friend" / "Submit to my employer" (ChatActionableButtons.tsx:242-252, DynamicReportDetailsPage.tsx:575-612), while the More row still calls createDraftTransactionAndNavigateToParticipantSelector with the default submitDestination = FRIEND.

So under the beta the new row is not the same flow as the Inbox: it silently gives you the friend path only.

Note: I don't think that blocks this PR. The row is labelled "Send to someone", so defaulting to the person destination is a defensible reading, and the split is a More-menu UX decision that wants Design input rather than a reviewer's guess.

But it should be a conscious call rather than a deferral, so: @shawnborton is single-destination correct for this row under the Submit plan, or should it split like the whisper does? If single-destination is intended, let's say so in the PR description and close #97881 on it.

If not, it's a follow-up issue and #97881 stays open on that half.

Thanks for the thorough pass, ikevin127. Pushed e26deb5 for the two code cleanups + the doc fixes. On the 🔴 blocker: it's stale against current main — details below with evidence.

🔴 navigateAfterOnboarding.ts — not a regression against current main (no change needed)

Your grep was correct at the time you ran it, but main has since moved that exact routing off categoriesRoute — twice — so the branch now matches current main, it doesn't revert it.

Recent main history for that file:

c275146 removed the WORKSPACE_CATEGORIES + backTo routing you quoted, and 8df2536 set it to SEARCH_ROOT/buildCannedSearchQuery — i.e. main itself now lands new Submit-workspace users on Spend › Expenses. The branch is byte-identical to that:

$ git diff origin/main HEAD -- src/libs/navigateAfterOnboarding.ts
(empty)
$ git show origin/main:src/libs/navigateAfterOnboarding.ts | grep -c categoriesRoute
0
$ git show HEAD:src/libs/navigateAfterOnboarding.ts        | grep -c categoriesRoute
0

So merging this PR changes that file by zero lines relative to current main, and there's no Submit-workspace onboarding regression. Applying git checkout <merge-base> -- navigateAfterOnboarding.ts would do the opposite of what's wanted now — it would re-introduce the pre-c275146 Categories routing that main deliberately removed yesterday. I've left the file untouched (it already matches main). If you re-verify, please git fetch first — the difference is entirely main moving under the earlier review.

🟡 Cleanups — done in e26deb5

• Unified the self-DM predicate. IOURequestStepAmount and IOURequestStepDistance now compute the pre-mount guard with isSelfDMSoleDestination(transaction?.participants ?? [], iouType, currentUserPersonalDetails.accountID) — the same predicate family as their navigate half — instead of isSelfDM(report), so it no longer leans on !reportID to paper over a mismatch. Both files still pass react-compiler-compliance-check (kept inline in Distance to stay under its memo-preservation limit).
• Test spy leak. Added afterEach(() => jest.restoreAllMocks()) to the SEND_TO_SOMEONE gate block in ReportSecondaryActionUtilsTest so its mockReturnValue spies stop leaking into later getSecondaryTransactionThreadActions cases.
• isLookingAroundUserSelector — agreed, leaving it as-is (stable useOnyx selector identity, mirrors isTrackIntentUserSelector). tgolen a quick 👍 on the selector form when you get a sec.
• PR Tests label. Fixed Submit it to someone → Send to someone throughout the description (the only remaining "Submit it to someone" is the intentional reference to the whisper copy in the whisper-resolution step).

🟡 Manual test steps — added

Rewrote the description's Tests / Offline / QA sections to cover the gaps you listed: whisper resolution after Send to someone, the split-expense gate (hidden without a workspace, shown with one), archived self-DM, delegate-restricted, invoice regression, submit-workspace onboarding regression, the Share flow, and QAB split out from scan-skip as its own step. Offline now has the optimistic-resolve + rollback-on-failure pair instead of the trivial "row still shows offline" step.

One correction on your suggested submit-workspace step: the expected landing is Spend › Expenses, not Workspace › Categories — per c275146/8df2536 above that's what current main does, and this PR doesn't touch that path, so it's framed as a "matches main" regression check.

Verification (Android)

Confirmed Bug 2 on standalone Android NewDot — created a self-tracked expense, opened its More menu:

Send to someone renders first with a divider beneath it, and tapping it opens the Choose recipient RHP.

More menu — "Send to someone" first, divider beneath

Choose recipient screen after tapping "Send to someone"

npm run fmt, ESLint, typecheck-tsgo, react-compiler-compliance-check (both step files), and the unit suites pass locally. (One local typecheck-tsgo error in tests/unit/postOrReplaceComment.ts is an env-only missing jest-when install — it's declared in package.json and isn't part of this PR, so CI is unaffected.)

🟢 Everything looks good code-wise - I'm moving to manual testing.

🧪 I ran the manual tests and found some issues that require fixes:

Setup

• Account A — brand-new signup, choose "Something else" at onboarding. No workspace. This is the primary account for everything below.
• Account B — Account A after you create a workspace on it (do this only once Gates 1 to 5 are done, since it changes A's behaviour). Used for the scoping negative case.
• Confirm SUBMIT_2026 is OFF on the test account before Gate 4. With it on, the More row intentionally differs from the whisper (deferred item awaiting @shawnborton), and you'd be testing a known-divergent state.

GATE 1 — Looking-Around landing, all four create paths (wide layout) ⚠️ (issues on Quick action flow)

Exercises getSubmitHandler → SEARCH_DISMISS and navigateAfterExpenseCreate.

1. Sign up as Account A, choose "Something else".
2. Pass: you land on Home. Not Spend, not Personal Space.
3. From Home, create an expense via global create (+), once for each entry type:
   • a. Manual amount, through the confirmation step
   • b. Manual amount via the quick action button (skips confirmation)
   • c. Scan a receipt, then skip confirmation
   • d. Distance, then skip confirmation
4. Pass: after each one you land on Spend › Expenses with the new expense visible.

These are four genuinely different code paths (useExpenseSubmission, IOUAmountSubmission, ScanSkipConfirmation, handleMoneyRequestStepDistanceNavigation). Report them individually. b/c/d only started working this round.

GATE 2 — No Personal Space flash on narrow layout ❌ (Failing on narrow even in the passing cases from GATE 1)

Exercises getSubmitExpensePreMountDestinationRoute and getSkipConfirmationPreMountDestinationRoute. Native + mWeb only — the guard is narrow-layout-specific, so this cannot be validated on desktop web.

1. On Account A, narrow layout (real device or a narrow window).
2. Repeat 3a to 3d from Gate 1.
3. Pass: the modal closes straight to Spend › Expenses. No flash of Personal Space / self-DM behind the closing RHP, and no stale self-DM left in the Inbox stack when you switch back to Inbox.

Worth recording video for at least c (scan-skip), since that's the highest-traffic new-user path and the one the pre-mount guard was added for.

GATE 3 — Scoping: a Looking-Around user with a workspace is NOT misrouted ⚠️ (Issue landing on Spend › Expenses)

This is the regression that took three rounds to get right. Exercises the isSelfDMDestination scoping in all three decision functions.

1. On Account A, create a workspace (or accept an invite).
2. From the Inbox, use global create to submit an expense to the workspace chat.
3. Pass: you land on the workspace chat, not Spend › Expenses.
4. Repeat with a Split or Pay to another person from global create.
5. Pass: you land on that DM/report.
6. Create an invoice from global create.
7. Pass: landing is unchanged from main behaviour. (isLookingAroundUser was removed from both invoice call sites this round.)

A failure here means the gate is keying off the onboarding choice alone again, which permanently misroutes anyone who ever picked "Something else."

GATE 4 — "Send to someone" row + whisper resolution ✅ PASSED

Exercises the getSecondaryTransactionThreadActions gate, TRANSACTION_MORE_MENU_SECTIONS ordering, and the getTrackExpenseActionableWhisper fix. Step 5 is the important one, it was the most severe bug found in this PR.

1. On Account A (no workspace), track an expense in Personal Space. Do not submit it.
2. Open Spend › Expenses, open the tracked expense, open the More (⋯) menu.
3. Pass: Send to someone is the first row, with a divider beneath it.
4. Tap it. Pass: the "Choose a recipient" RHP opens, identical to the one from the Inbox whisper. Pick a recipient and complete the submit.
5. Go back to Personal Space and find the original track-expense whisper. Pass: the whisper is resolved and no longer offers "Submit it to someone / Categorize it / Share it" for that expense.

If step 5 fails, the whisper is being left stranded and the expense can be re-entered into a convert flow it already completed.

GATE 5 — The row hides when it should ✅ PASSED

Same gate, negative cases.

1. Reopen the More menu on the expense you just sent. Pass: Send to someone is gone (parent is no longer a self-DM).
2. On an account with no workspace, create a split expense in Personal Space, open the child transaction's More menu. Pass: Send to someone is not shown.
3. Join or create a workspace, reopen that same split expense's More menu. Pass: Send to someone now is shown.
4. Open the More menu on a regular submitted expense (not tracked). Pass: the row is absent.

Step 2/3 is the !isSelfDMExpenseSplit || hasWorkspaceToSubmitTo guard added this round. Without it the picker opens onto a flow with no valid destination.

GATE 6 — Offline ⚠️ (Same issues on Quick action as GATE 1)

1. Turn off the network.
2. As Account A on Home, create an expense. Pass: you still land on Spend › Expenses with the optimistic (greyed) row visible, no error.
3. On a tracked expense, tap Send to someone, pick a recipient, submit. Pass: the expense converts optimistically and the self-DM whisper resolves optimistically.
4. Restore the connection. Pass: both stick, and there's no second navigation jump when the response lands.
5. Force a failure on the same submit. Pass: the whisper rolls back to unresolved.

Step 5 matters because the rollback is gated on the same actionableWhisperReportActionID that was undefined two rounds ago. Optimistic-success passing does not prove the rollback path works.

🔄 Working on the fixes locally so I can let Melvin know and have all 6 GATES pass.

Local patch: Gates 1, 2, 3 and 6

I applied a fix locally and re-ran the merge gates. All six now pass, including Gate 2 on narrow, which I'd previously flagged as out of scope. It turned out to be fixable without touching shared behaviour, so no follow-up is needed on this PR.

diff --git a/src/libs/IOUAmountSubmission.ts b/src/libs/IOUAmountSubmission.ts
index 15a873e4a7d..4bfc4fa0b78 100644
--- a/src/libs/IOUAmountSubmission.ts
+++ b/src/libs/IOUAmountSubmission.ts
@@ -436,6 +436,9 @@ function submitSkipConfirmationExpense(args: SubmitAmountArgs, ctx: SubmitAmount
     submitWithDismissFirst({
         executeWrite: executeExpenseWrite,
         destinationReportID: isTrackExpenseSubmit ? (report?.reportID ?? selfDMReport?.reportID) : report?.reportID,
+        isFromGlobalCreate: getIsFromGlobalCreate(transaction),
+        isLookingAroundUser: introSelected?.choice === CONST.ONBOARDING_CHOICES.LOOKING_AROUND,
+        isSelfDMDestination,
         telemetryContext: {
             scenario: isTrackExpenseSubmit ? CONST.TELEMETRY.SUBMIT_EXPENSE_SCENARIO.TRACK_EXPENSE : CONST.TELEMETRY.SUBMIT_EXPENSE_SCENARIO.REQUEST_MONEY_MANUAL,
             iouType,
diff --git a/src/libs/Navigation/helpers/navigateAfterExpenseCreate.ts b/src/libs/Navigation/helpers/navigateAfterExpenseCreate.ts
index 60218e882ad..05b151c1b96 100644
--- a/src/libs/Navigation/helpers/navigateAfterExpenseCreate.ts
+++ b/src/libs/Navigation/helpers/navigateAfterExpenseCreate.ts
@@ -114,7 +114,11 @@ function navigateAfterExpenseCreate({
         } else if (getIsNarrowLayout()) {
             const isRHPStillOnTop = navigationRef.getRootState()?.routes?.at(-1)?.name === NAVIGATORS.RIGHT_MODAL_NAVIGATOR;
             if (!alreadyOnSearchRoot || !isSameSearchType || isRHPStillOnTop) {
-                Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: queryString}), {forceReplace: true});
+                // forceReplace makes linkTo dispatch a REPLACE against TAB_NAVIGATOR, but SEARCH.ROOT is in linkTo's
+                // ROOT_TAB_SCREENS, so the cross-tab PUSH branch is skipped and the REPLACE resolves to a no-op, leaving
+                // the user on the tab they submitted from. Skipped only for the LOOKING_AROUND self-DM flow so every
+                // other caller keeps its existing history behaviour.
+                Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: queryString}), {forceReplace: !(isLookingAroundUser && isSelfDMDestination)});
             } else {
                 Log.info('[IOU] navigateToSearch: already on matching Search root with RHP dismissed - no-op');
             }
diff --git a/src/libs/Navigation/helpers/submitWithDismissFirst.ts b/src/libs/Navigation/helpers/submitWithDismissFirst.ts
index de854b12f26..4ed2455cc95 100644
--- a/src/libs/Navigation/helpers/submitWithDismissFirst.ts
+++ b/src/libs/Navigation/helpers/submitWithDismissFirst.ts
@@ -24,6 +24,12 @@ type SubmitWithDismissFirstParams = {
     destinationReportID: string | undefined;
     /** Telemetry metadata for the submit-expense performance span. */
     telemetryContext: SubmitExpenseContext;
+    /** Whether the expense was initiated from the global FAB (no pre-existing report context). */
+    isFromGlobalCreate?: boolean;
+    /** Whether the user onboarded as "Something else" (LOOKING_AROUND) - they have no workspace. */
+    isLookingAroundUser?: boolean;
+    /** Whether the sole destination for this expense is the current user's self-DM (Personal Space). */
+    isSelfDMDestination?: boolean;
 };
 
 function startDismissFirstTracking(
@@ -47,14 +53,22 @@ function startDismissFirstTracking(
  *
  *   1. Search topmost            -> dismiss modal, defer write for Search skeleton
  *   2. Route pre-inserted        -> dismiss modal, write after transition (route already staged)
- *   3. Destination already shown -> dismiss modal, write after transition
- *   4. Destination loaded        -> reveal destination then dismiss, write after transition
- *   5. Destination not loaded    -> write immediately, then reveal-and-dismiss
- *   6. Fallback                  -> start tracking with default fast path, write with defaults
+ *   3. Looking-Around self-DM    -> write owns navigation (routes to Search via navigateAfterExpenseCreate)
+ *   4. Destination already shown -> dismiss modal, write after transition
+ *   5. Destination loaded        -> reveal destination then dismiss, write after transition
+ *   6. Destination not loaded    -> write immediately, then reveal-and-dismiss
+ *   7. Fallback                  -> start tracking with default fast path, write with defaults
  *
  * Must not be called from `src/libs/actions/` — view-layer only.
  */
-function submitWithDismissFirst({executeWrite, destinationReportID, telemetryContext}: SubmitWithDismissFirstParams): void {
+function submitWithDismissFirst({
+    executeWrite,
+    destinationReportID,
+    telemetryContext,
+    isFromGlobalCreate = false,
+    isLookingAroundUser = false,
+    isSelfDMDestination = false,
+}: SubmitWithDismissFirstParams): void {
     const shouldStayOnSearch = isSearchTopmostFullScreenRoute();
 
     if (shouldStayOnSearch) {
@@ -75,6 +89,18 @@ function submitWithDismissFirst({executeWrite, destinationReportID, telemetryCon
         return;
     }
 
+    // "Something else" (LOOKING_AROUND) users have no workspace, so a global-create expense lands in their self-DM, but
+    // the product requirement is to route them to Spend > Expenses instead. Every dismiss-first branch below calls
+    // executeWrite with shouldHandleNavigation: false, and cleanupAfterSkipConfirmSubmit drops the routing flags in that
+    // case - so navigateAfterExpenseCreate never runs and the destinationReportID branch reveals the self-DM. Hand
+    // navigation back to the write, same as the fallback below, so navigateAfterExpenseCreate owns the Search routing.
+    if (isFromGlobalCreate && isLookingAroundUser && isSelfDMDestination) {
+        startTracking(telemetryContext, {skipSubmitExpenseSpan: true});
+        setFastPath(CONST.TELEMETRY.FAST_PATH_HANDLER.DEFAULT);
+        executeWrite({shouldHandleNavigation: true});
+        return;
+    }
+
     if (destinationReportID) {
         const isDestinationLoaded = !!getReportOrDraftReport(destinationReportID)?.reportID;
         const isNarrow = getIsNarrowLayout();
diff --git a/src/pages/iou/request/step/IOURequestStepAmount.tsx b/src/pages/iou/request/step/IOURequestStepAmount.tsx
index 596c6cee24a..3da031edd08 100644
--- a/src/pages/iou/request/step/IOURequestStepAmount.tsx
+++ b/src/pages/iou/request/step/IOURequestStepAmount.tsx
@@ -21,7 +21,7 @@ import Log from '@libs/Log';
 import {getAmountHasUnsavedChanges} from '@libs/MoneyRequestUtils';
 import Navigation from '@libs/Navigation/Navigation';
 import {getParticipantsOption, getReportOption} from '@libs/OptionsListUtils';
-import {getTransactionDetails, isMoneyRequestReport, isPolicyExpenseChat, shouldEnableNegative} from '@libs/ReportUtils';
+import {getTransactionDetails, isMoneyRequestReport, isPolicyExpenseChat, isSelfDM, shouldEnableNegative} from '@libs/ReportUtils';
 import {getRequestType, isDistanceRequest, isExpenseUnreported} from '@libs/TransactionUtils';
 
 import MoneyRequestAmountForm from '@pages/iou/MoneyRequestAmountForm';
@@ -159,13 +159,16 @@ function IOURequestStepAmount({
         return !(isReportArchived || isPolicyExpenseChat(report));
     }, [report, isSplitBill, skipConfirmation, isReportArchived]);
 
-    // Use the same self-DM predicate as the navigate half (IOUAmountSubmission) so the pre-mount guard suppresses in exactly
-    // the cases where navigation forces Search, rather than relying on report?.reportID being undefined to cover a mismatch.
+    // Both self-DM signals are ORed on purpose. The navigate half (IOUAmountSubmission) reads participants at submit time,
+    // but on a quick-action flow they are not populated yet when this pre-mount decision runs, so the participants check
+    // alone misses and the self-DM gets pre-inserted - then navigateAfterExpenseCreate reveals it instead of going to Search.
+    // isSelfDM(report) answers the question this site actually cares about ("is the report I am about to pre-insert the
+    // self-DM?") and is available immediately.
     const skipConfirmationPreMountRoute = getSkipConfirmationPreMountDestinationRoute(
         shouldSkipConfirmation,
         report?.reportID,
         isLookingAroundUser,
-        isSelfDMSoleDestination(transaction?.participants ?? [], iouType, currentUserPersonalDetails.accountID),
+        isSelfDM(report) || isSelfDMSoleDestination(transaction?.participants ?? [], iouType, currentUserPersonalDetails.accountID),
     );
     usePreMountDestination(skipConfirmationPreMountRoute);
 
diff --git a/src/pages/iou/request/step/IOURequestStepDistance.tsx b/src/pages/iou/request/step/IOURequestStepDistance.tsx
index c8f98e35874..6ff5b44b283 100644
--- a/src/pages/iou/request/step/IOURequestStepDistance.tsx
+++ b/src/pages/iou/request/step/IOURequestStepDistance.tsx
@@ -41,7 +41,7 @@ import Navigation from '@libs/Navigation/Navigation';
 import OnyxTabNavigator, {TabScreenWithFocusTrapWrapper, TopTab} from '@libs/Navigation/OnyxTabNavigator';
 import {roundToTwoDecimalPlaces} from '@libs/NumberUtils';
 import {isTrackOnboardingChoice} from '@libs/OnboardingUtils';
-import {isPolicyExpenseChat as isPolicyExpenseChatUtil} from '@libs/ReportUtils';
+import {isPolicyExpenseChat as isPolicyExpenseChatUtil, isSelfDM} from '@libs/ReportUtils';
 import {getDistanceInMeters, getRateID, getRequestType, getSelectedRouteKey, hasManualDistanceOverride, haveWaypointAddressesChanged} from '@libs/TransactionUtils';
 
 import CONST from '@src/CONST';
@@ -321,7 +321,9 @@ function IOURequestStepDistance({
         introSelected?.choice === CONST.ONBOARDING_CHOICES.LOOKING_AROUND,
         // Same self-DM predicate as the navigate half (handleMoneyRequestStepDistanceNavigation) so the guard suppresses in
         // exactly the cases navigation forces Search. Kept inline to stay under this component's React Compiler memo limit.
-        isSelfDMSoleDestination(transaction?.participants ?? [], iouType, currentUserPersonalDetails.accountID),
+        // Both self-DM signals are ORed: on a quick-action flow participants are not populated yet when this runs, so the
+        // participants check alone misses and the self-DM gets pre-inserted, which navigateAfterExpenseCreate then reveals.
+        isSelfDM(report) || isSelfDMSoleDestination(transaction?.participants ?? [], iouType, currentUserPersonalDetails.accountID),
     );
     usePreMountDestination(skipConfirmationPreMountRoute);
 
diff --git a/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts b/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts
index ccc2596400b..8dcf697f64b 100644
--- a/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts
+++ b/src/pages/iou/request/step/IOURequestStepDistance/handleMoneyRequestStepDistanceNavigation.ts
@@ -279,6 +279,9 @@ function handleMoneyRequestStepDistanceNavigation({
 
             if (isCreatingTrackExpense && participant) {
                 submitWithDismissFirst({
+                    isFromGlobalCreate: transactionIsFromGlobalCreate,
+                    isLookingAroundUser,
+                    isSelfDMDestination,
                     // trackExpense is a void action with no navigation params; submitWithDismissFirst owns dismiss/reveal and cleanup runs after.
                     executeWrite: (overrides) => {
                         trackExpense({
@@ -366,6 +369,9 @@ function handleMoneyRequestStepDistanceNavigation({
             const distanceDestinationReportID = report?.reportID;
 
             submitWithDismissFirst({
+                isFromGlobalCreate: transactionIsFromGlobalCreate,
+                isLookingAroundUser,
+                isSelfDMDestination,
                 executeWrite: (overrides) => {
                     const {transactionID: writtenDistanceTransactionID} = createDistanceRequest({
                         report,
diff --git a/src/pages/iou/request/step/IOURequestStepScan/components/ScanSkipConfirmation.tsx b/src/pages/iou/request/step/IOURequestStepScan/components/ScanSkipConfirmation.tsx
index c8813b5077a..a0b894cc11c 100644
--- a/src/pages/iou/request/step/IOURequestStepScan/components/ScanSkipConfirmation.tsx
+++ b/src/pages/iou/request/step/IOURequestStepScan/components/ScanSkipConfirmation.tsx
@@ -323,6 +323,9 @@ function ScanSkipConfirmation({report, action, iouType, reportID, transactionID,
 
         const scanDestinationReportID = iouType === CONST.IOU.TYPE.TRACK ? (report?.reportID ?? selfDMReport?.reportID) : report?.reportID;
         submitWithDismissFirst({
+            isFromGlobalCreate,
+            isLookingAroundUser,
+            isSelfDMDestination,
             executeWrite: (overrides) => {
                 // Cleanup runs after each write (not once up front) so a stalled GPS lookup can't clear the draft before the expense exists.
                 const runCleanup = () =>
diff --git a/src/pages/iou/request/step/confirmation/SubmitExpenseOrchestrator.tsx b/src/pages/iou/request/step/confirmation/SubmitExpenseOrchestrator.tsx
index ab4ea05e1a9..c681ccedf29 100644
--- a/src/pages/iou/request/step/confirmation/SubmitExpenseOrchestrator.tsx
+++ b/src/pages/iou/request/step/confirmation/SubmitExpenseOrchestrator.tsx
@@ -284,6 +284,12 @@ function SubmitExpenseOrchestrator({
         // When Search is not visible (e.g. submitting from Home/Settings), we must navigate there.
         const isSearchVisible = isSearchTopmostFullScreenRoute();
         const shouldNavigateToSearch = !isSameType || !isSearchVisible;
+        // forceReplace makes linkTo dispatch a REPLACE against TAB_NAVIGATOR, but SEARCH.ROOT is in linkTo's
+        // ROOT_TAB_SCREENS, so the cross-tab PUSH branch is skipped and the REPLACE resolves to a no-op: the mounted
+        // tab navigator keeps its state and the user stays on the tab they submitted from. Skipping forceReplace makes
+        // the navigation actually happen. Scoped to the LOOKING_AROUND self-DM flow this fix is about - other callers
+        // keep forceReplace so their browser-history behaviour is unchanged, even though they hit the same no-op today.
+        const shouldSkipForceReplace = isFromGlobalCreateForNavigation && isLookingAroundUser && isSelfDMDestination;
         setPendingSubmitFollowUpAction(shouldNavigateToSearch ? CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.NAVIGATE_TO_SEARCH : CONST.TELEMETRY.SUBMIT_FOLLOW_UP_ACTION.DISMISS_MODAL_ONLY);
         reserveDeferredWriteChannel(CONST.DEFERRED_LAYOUT_WRITE_KEYS.SEARCH);
 
@@ -321,7 +327,7 @@ function SubmitExpenseOrchestrator({
                         return;
                     }
 
-                    Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: buildCannedSearchQuery({type: searchType})}), {forceReplace: true});
+                    Navigation.navigate(ROUTES.SEARCH_ROOT.getRoute({query: buildCannedSearchQuery({type: searchType})}), {forceReplace: !shouldSkipForceReplace});
                 });
             },
         });
diff --git a/tests/unit/navigateAfterExpenseCreateTest.ts b/tests/unit/navigateAfterExpenseCreateTest.ts
index c17fecc6ddf..26ec395ea9a 100644
--- a/tests/unit/navigateAfterExpenseCreateTest.ts
+++ b/tests/unit/navigateAfterExpenseCreateTest.ts
@@ -112,10 +112,30 @@ describe('navigateAfterExpenseCreate', () => {
             isSelfDMDestination: true,
         });
 
-        expect(Navigation.navigate).toHaveBeenCalledWith(ROUTES.SEARCH_ROOT.getRoute({query: 'type:expense'}), {forceReplace: true});
+        // forceReplace is deliberately false here: it makes linkTo dispatch a REPLACE against TAB_NAVIGATOR, and because
+        // SEARCH.ROOT is a tab root that REPLACE is a no-op, which left these users stuck on the tab they submitted from.
+        expect(Navigation.navigate).toHaveBeenCalledWith(ROUTES.SEARCH_ROOT.getRoute({query: 'type:expense'}), {forceReplace: false});
         expect(Navigation.dismissModalWithReport).not.toHaveBeenCalled();
     });
 
+    it('should keep forceReplace for a narrow Search navigation that is not the LOOKING_AROUND self-DM flow', () => {
+        // The forceReplace opt-out is scoped to the flow this fix is about, so every other caller keeps its existing
+        // browser-history behaviour even though they hit the same linkTo no-op today.
+        mockIsReportTopmostSplitNavigator.mockReturnValue(false);
+        mockGetIsNarrowLayout.mockReturnValue(true);
+
+        navigateAfterExpenseCreate({
+            activeReportID: 'report-123',
+            transactionID: 'txn-1',
+            isFromGlobalCreate: true,
+            hasMultipleTransactions: false,
+            isLookingAroundUser: false,
+            isSelfDMDestination: false,
+        });
+
+        expect(Navigation.navigate).toHaveBeenCalledWith(ROUTES.SEARCH_ROOT.getRoute({query: 'type:expense'}), {forceReplace: true});
+    });
+
     it('should NOT route a LOOKING_AROUND user to search when the destination is a real report (not the self-DM)', () => {
         // A LOOKING_AROUND user who later has a workspace and submits to a real report/friend from the Inbox must open that
         // report, not be permanently misrouted to Search. isSelfDMDestination is false, so they are treated as "on inbox".
diff --git a/tests/unit/submitWithDismissFirstTest.ts b/tests/unit/submitWithDismissFirstTest.ts
index e826ea351ed..e3fc66ddfd6 100644
--- a/tests/unit/submitWithDismissFirstTest.ts
+++ b/tests/unit/submitWithDismissFirstTest.ts
@@ -194,6 +194,106 @@ describe('submitWithDismissFirst', () => {
         });
     });
 
+    describe('Looking-Around self-DM branch', () => {
+        const LOOKING_AROUND_SELF_DM = {
+            isFromGlobalCreate: true,
+            isLookingAroundUser: true,
+            isSelfDMDestination: true,
+        };
+
+        it('hands navigation to the write instead of revealing the self-DM report', () => {
+            // Without this branch the destination-report fast path reveals the self-DM and calls executeWrite with
+            // shouldHandleNavigation: false, which makes cleanupAfterSkipConfirmSubmit drop the routing flags before
+            // navigateAfterExpenseCreate can route these users to Spend > Expenses.
+            mockGetReportOrDraftReport.mockReturnValue({reportID: 'selfDM1'});
+            const executeWrite = jest.fn();
+
+            submitWithDismissFirst({
+                executeWrite,
+                destinationReportID: 'selfDM1',
+                telemetryContext: TELEMETRY_CONTEXT,
+                ...LOOKING_AROUND_SELF_DM,
+            });
+
+            expect(executeWrite).toHaveBeenCalledWith({shouldHandleNavigation: true});
+            expect(mockRevealRouteBeforeDismissingModal).not.toHaveBeenCalled();
+            expect(mockDismissModal).not.toHaveBeenCalled();
+        });
+
+        it('still starts tracking so telemetry is not skipped', () => {
+            mockGetReportOrDraftReport.mockReturnValue({reportID: 'selfDM1'});
+
+            submitWithDismissFirst({
+                executeWrite: jest.fn(),
+                destinationReportID: 'selfDM1',
+                telemetryContext: TELEMETRY_CONTEXT,
+                ...LOOKING_AROUND_SELF_DM,
+            });
+
+            expect(mockStartTracking).toHaveBeenCalledWith(TELEMETRY_CONTEXT, {skipSubmitExpenseSpan: true});
+            expect(mockSetFastPath).toHaveBeenCalledWith(CONST.TELEMETRY.FAST_PATH_HANDLER.DEFAULT);
+        });
+
+        it('does not divert when the destination is not the self-DM', () => {
+            mockGetReportOrDraftReport.mockReturnValue({reportID: 'r1'});
+            const executeWrite = jest.fn();
+
+            submitWithDismissFirst({
+                executeWrite,
+                destinationReportID: 'r1',
+                telemetryContext: TELEMETRY_CONTEXT,
+                ...LOOKING_AROUND_SELF_DM,
+                isSelfDMDestination: false,
+            });
+
+            expect(mockRevealRouteBeforeDismissingModal).toHaveBeenCalled();
+            expect(executeWrite).not.toHaveBeenCalledWith({shouldHandleNavigation: true});
+        });
+
+        it('does not divert when the expense is not from global create', () => {
+            mockGetReportOrDraftReport.mockReturnValue({reportID: 'selfDM1'});
+
+            submitWithDismissFirst({
+                executeWrite: jest.fn(),
+                destinationReportID: 'selfDM1',
+                telemetryContext: TELEMETRY_CONTEXT,
+                ...LOOKING_AROUND_SELF_DM,
+                isFromGlobalCreate: false,
+            });
+
+            expect(mockRevealRouteBeforeDismissingModal).toHaveBeenCalled();
+        });
+
+        it('does not divert for a non-Looking-Around user', () => {
+            mockGetReportOrDraftReport.mockReturnValue({reportID: 'selfDM1'});
+
+            submitWithDismissFirst({
+                executeWrite: jest.fn(),
+                destinationReportID: 'selfDM1',
+                telemetryContext: TELEMETRY_CONTEXT,
+                ...LOOKING_AROUND_SELF_DM,
+                isLookingAroundUser: false,
+            });
+
+            expect(mockRevealRouteBeforeDismissingModal).toHaveBeenCalled();
+        });
+
+        it('yields to the Search-topmost branch, which already leaves the user on Search', () => {
+            mockIsSearchTopmostFullScreenRoute.mockReturnValue(true);
+            const executeWrite = jest.fn();
+
+            submitWithDismissFirst({
+                executeWrite,
+                destinationReportID: 'selfDM1',
+                telemetryContext: TELEMETRY_CONTEXT,
+                ...LOOKING_AROUND_SELF_DM,
+            });
+
+            expect(mockDismissModal).toHaveBeenCalledTimes(1);
+            expect(executeWrite).not.toHaveBeenCalled();
+        });
+    });
+
     describe('Priority', () => {
         it('Search-topmost takes priority over destination report', () => {
             mockIsSearchTopmostFullScreenRoute.mockReturnValue(true);

10 files, +187 / −14.

Fix 1 — the skip-confirmation flags never reached the navigator (Gates 1, 3, 6)

e26deb5 threaded isLookingAroundUser and isSelfDMDestination into the three skip-confirmation call sites, but they never reached the code that uses them.

cleanupAfterSkipConfirmSubmit forwards only two fields when navigation is already handled:

function cleanupAfterSkipConfirmSubmit(shouldHandleNavigation: boolean, params: CleanupAndNavigateAfterExpenseCreateParams) {
    if (shouldHandleNavigation) {
        cleanupAndNavigateAfterExpenseCreate(params);
        return;
    }
    // isLookingAroundUser and isSelfDMDestination are dropped here
    cleanupAfterExpenseCreate({draftTransactionIDs: params.draftTransactionIDs, linkedTrackedExpenseReportAction: params.linkedTrackedExpenseReportAction});
}

And submitWithDismissFirst passes shouldHandleNavigation: false on every branch except the final fallback, which only fires when destinationReportID is undefined. For these users it is report?.reportID ?? selfDMReport?.reportID, always defined, so the branch taken was:

Navigation.revealRouteBeforeDismissingModal(ROUTES.REPORT_WITH_ID.getRoute(destinationReportID));

which reveals and dismisses to the self-DM. navigateAfterExpenseCreate was never called on QAB, scan-skip or distance-skip.

Same root cause as the 2026-08-07 fix, one layer over. That round correctly taught getSubmitHandler, the confirmation-step orchestrator, about LOOKING_AROUND. submitWithDismissFirst is the skip-confirmation orchestrator and needed the equivalent branch.

The change: a new branch in submitWithDismissFirst that hands navigation back to the write, so navigateAfterExpenseCreate owns the Search routing. It reuses the branch that already works on the confirmation path rather than duplicating navigation logic, and sits after the Search-topmost and pre-inserted checks (both already correct for these users) and before the destination-report reveal.

Threaded at four call sites, all of which already had the values in scope: IOUAmountSubmission (QAB), ScanSkipConfirmation (single expense), and both handleMoneyRequestStepDistanceNavigation sites. Deliberately not threaded at the other three: the two PAY / send-money callers and the scan split caller. isSelfDMSoleDestination returns false for PAY and SPLIT, so passing there would be dead threading, which is what caused the previous two rounds of this bug.

Fix 2 — narrow layout (Gate 2)

Two separate causes, both confirmed with console instrumentation on narrow desktop Chrome and iOS mWeb Safari.

2a. forceReplace silently no-ops when the target is a tab root

The handler choice was already correct (SEARCH_DISMISS fired), shouldNavigateToSearch was true, and Navigation.navigate was called with a valid route. React Navigation then did nothing. Reason, in linkTo:

// index.ts:34
const ROOT_TAB_SCREENS = new Set<string>([SCREENS.HOME, SCREENS.INBOX, SCREENS.SEARCH.ROOT, SCREENS.SETTINGS.ROOT, SCREENS.WORKSPACES_LIST]);

// index.ts:179
if (forceReplace) {
    action.type = CONST.NAVIGATION.ACTION_TYPE.REPLACE;
}

// index.ts:215 - the cross-tab handler that would normally PUSH
const isTargetAtTabRoot = ROOT_TAB_SCREENS.has(focusedRouteFromPath?.name ?? '');
if (currentActiveScreen && targetActiveScreen && currentActiveScreen !== targetActiveScreen && !isTargetAtTabRoot) {
    action.type = PUSH;
    navigation.dispatch(action);
    return;
}

SCREENS.SEARCH.ROOT is a tab root, so the cross-tab branch is skipped ("plain tab switch") and what gets dispatched is a REPLACE on TAB_NAVIGATOR while TAB_NAVIGATOR is already the top route. Replacing the tab navigator with itself preserves the mounted navigator's state, so the user stays on the tab they submitted from and no state change is emitted.

This also produced a second symptom: handleSearchDismiss reserves the deferred-write channel for Search before dismissing, so with the navigation not landing, the Search screen never laid out and TrackExpense sat behind the 5000ms DeferredLayoutWrite safety timeout before being sent. Fixing the navigation fixes the latency too.

Fixed by skipping forceReplace in SubmitExpenseOrchestrator.handleSearchDismiss and in navigateAfterExpenseCreate's narrow branch (both had the identical line).

2b. The skip-confirmation pre-mount guard missed on quick-action flows

IOURequestStepAmount and IOURequestStepDistance were computing the guard's isSelfDMDestination from isSelfDMSoleDestination(transaction?.participants ?? [], ...). On a quick-action flow the participants are not populated yet when that pre-mount decision runs, so the guard returned false, the self-DM got pre-inserted, and navigateAfterExpenseCreate then revealed it via:

if (getIsNarrowLayout() && Navigation.getIsFullscreenPreInsertedUnderRHP()) {
    Navigation.clearFullscreenPreInsertedFlag();
    Navigation.dismissModal();   // reveals the pre-inserted self-DM
}

The two sites need different information at different times. The pre-mount asks "is the report I am about to pre-insert the self-DM?", which isSelfDM(report) answers immediately; the navigate asks "is the destination the self-DM?", which is only correct at submit time. Both signals are now ORed at the two pre-mount sites.

(For the record, unifying on isSelfDMSoleDestination was my suggestion in the previous round. It was right for the navigate half and wrong for the pre-mount half.)

Gating: nothing outside this PR's flow changes

This matters because handleSearchDismiss and navigateAfterExpenseCreate are shared narrow navigation used by other flows. Every behaviour change is gated on the same three conditions as the getSubmitHandler branch, and all flags default to false:

For any non-LOOKING_AROUND user, and for any LOOKING_AROUND user whose expense does not land in the self-DM, behaviour is bit-identical to main — forceReplace: true is preserved, the branch order in submitWithDismissFirst is unchanged, and pre-insert eligibility is unchanged. The callers I deliberately left alone (PAY / send-money, scan split) omit the params entirely and take the defaults.

Pinned by tests: navigateAfterExpenseCreateTest now asserts forceReplace: false for the LOOKING_AROUND self-DM case and forceReplace: true for a narrow Search navigation that is not it, so a future refactor cannot quietly widen the opt-out.

Deliberately not fixed here

The underlying linkTo bug is real and untouched: forceReplace no-ops for any tab-root target, so other narrow flows that reach SEARCH_DISMISS (e.g. a workspace user creating an expense from Home, via getSubmitHandler's last branch) are likely affected on staging and production today. Fixing that properly belongs in linkTo so forceReplace is honoured for tab roots, which would touch every caller. That is out of scope here and worth its own issue. Scoping our fix to this flow means we neither depend on it nor regress it.

Verification

• 261 tests pass across the 6 related suites. New: 6 cases in submitWithDismissFirstTest (branch fires; yields to Search-topmost; three negatives for non-self-DM destination, non-global-create, non-Looking-Around) and 1 in navigateAfterExpenseCreateTest pinning the forceReplace scoping. One existing assertion in navigateAfterExpenseCreateTest was updated from forceReplace: true to false, since that is the fix.
• typecheck-tsgo clean, npm run fmt applied, React Compiler compliance passes on ScanSkipConfirmation, IOURequestStepAmount, IOURequestStepDistance and SubmitExpenseOrchestrator.
• ESLint could not run in my environment (eslint-plugin-storybook throws ERR_REQUIRE_ESM on Node 20.13, unrelated to the change), so please rely on CI for that one.

Gate results after the patch

@MelvinBot please apply the changes above using the diff as the guide.

Applied your patch verbatim in 33df2b1 — 10 files, +187 / −14, exactly matching the diff. Credited you as co-author on the commit. Fast-forward push, no history rewrite.

What landed

• submitWithDismissFirst LOOKING_AROUND self-DM branch that hands navigation back to the write, threaded from the four call sites that had the values in scope (IOUAmountSubmission, ScanSkipConfirmation, both handleMoneyRequestStepDistanceNavigation sites); PAY/SPLIT callers left on defaults.
• forceReplace opt-out in navigateAfterExpenseCreate's narrow branch and SubmitExpenseOrchestrator.handleSearchDismiss, scoped to the flow.
• isSelfDM(report) || isSelfDMSoleDestination(...) in the IOURequestStepAmount and IOURequestStepDistance pre-mount guards.
• Test updates: the new submitWithDismissFirst LOOKING_AROUND describe block and the forceReplace scoping cases in navigateAfterExpenseCreateTest.

Verification I ran

• typecheck-tsgo: changed files clean. (One unrelated error surfaced in tests/unit/postOrReplaceComment.ts — a missing jest-when dev dep that isn't installed in this environment and isn't a file I touched; CI has it.)
• npm run fmt applied; ESLint on the changed files reports 0 errors (2 warnings, both pre-existing grandfathered set-state-in-effect at lines I didn't touch).
• Unit suites green: submitWithDismissFirstTest, navigateAfterExpenseCreateTest, getSkipConfirmationPreMountDestinationRouteTest, getSubmitExpensePreMountDestinationRouteTest, getSubmitHandlerTest, cleanupAndNavigateAfterExpenseCreateTest — all pass, including the new/updated cases.

One caveat: I couldn't add a live web pass on top of your manual verification — the prestarted web session was handed off in a blank, unresponsive state (empty accessibility tree, no interactive surface) that didn't recover, so there was nothing to drive. Since your patch already carries the six-gate manual results and the change is gated to the LOOKING_AROUND self-DM flow, I'm relying on that plus the green unit suites here. Please still lean on CI for the full lint/typecheck/test run.

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

@Expensify/design 🟢 Completed the PR Reviewer Checklist: this looks good to me and seems complete. Now before we merge it I'd want design to actually trigger an adhoc build and test the issue-expected flows on both web and mobile layouts and confirm that the issue's expected result was achieved.

⚠️ 🧪 Then possibly have QA run a regression test run on the adhoc as well in order to catch any regressions / potential deploy blockers before we actually merge - I did gate the narrow layout change specifically to the flows that this issue / PR are touching (see this comment), but still - if possible it would be good to have.